監視用アプリケーションを作りクラスタ切り替え時間を30秒に短縮

　OSはクラスタ機能を標準装備するWindows 2000 Advanced Serverを採用することに決定し，アプリケーション開発も大きな問題なく順調に進んでいた。

　しかし，システムの信頼性の面で大きな問題に直面した。標準のクラスタ機能を使うと，フェイル・オーバーに約3分かかる。一般的なクラスタ用途では許容される時間だが，出光興産の生産系システムでは運用に支障をきたすリスクがあった。

図2●クラスタの切り替え時間を約30秒に短縮する仕掛け 出光興産はクラスタの切り替え時間を減らすために，サーバーがダウンする前兆を察知して，問題が起こる前にもう1台のサーバーに切り替える仕組みを取り入れた。この仕組みを使わない場合，切り替えに要する時間は約3分だったが，現在は約30秒程度にまで短縮できた。

　出光興産はこの問題を解決するためのプロジェクト・チームを発足し，早速調査に乗り出した。クラスタの切り替え時間には，待機サーバーが本番サーバーのダウンをハートビート（本番サーバーの稼働状況を確認するために一定間隔で発信する信号）によって検知・確認するまでの時間や，サーバー間のリソース（ディスクなど）の引き継ぎ時間，アプリケーションの引き継ぎ時間などが含まれる。

　実際のフェイル・オーバーの動作を計測したところ，「サーバーのダウンを検知してから，本当にダウンしていることを確認するまでの時間が特に長かった」（製造部プロセスシステムセンターの竹沢宏氏）。

　クラスタの切り替え時間を短縮するための解決策として，出光興産は斬新な仕掛けを用意した。稼働中のサーバーがダウンする予兆をいち早く察知して，問題が起こる前にもう1台のサーバーに切り替えるというものだ（図2[拡大表示]）。こうすれば，待機サーバーが本番サーバーのダウンを検知・確認するまでの時間が不要になる。

　ダウンの予兆を察知するには，サーバーのメモリーの空き容量やプロセス数などを常時チェックする。一定のしきい値を超えるとダウンの危険性が高くなるのだ。「どういう状況になるとOSがダウンする可能性があるか，大まかなしきい値はあらかじめ把握していた。これを基にテスト段階で微調整した」（竹沢氏）という。出光興産は独自のサーバー監視プログラムを作成し，所定のしきい値を超えたら待機サーバーに切り替えるための処理をスタートさせる仕組みにした。

　この工夫により，クラスタの切り替え時間は3分から30秒程度にまで，大幅に短縮された。竹沢氏は「別のクラスタ製品を使うことで，さらに切り替え時間を短縮できる見込みだ」と次の課題に取り掛かっている。

各工場に分散していた情報を本社から直接閲覧可能に

　プラットフォームの変更と同時に，業務の合理化も進めていた。現状の業務の問題点を調査したところ，年間5万2900時間にも及ぶ延べ作業時間の大部分に合理化（システム化）の余地があることを突き止めた。

　その中でも，特に荷繰（にぐり）調整作業に無駄な時間を使っていた。荷繰調整とは，顧客が指定した期日までにきちんと商品を届けられるかどうかを，正式な受注前に判断する作業である。各工場の従業員は，本社の需給部から受け取った受注内容と，各工場の荷繰調整システムから得られる油の情報（調合する油があるか）や船の運行情報（船が桟橋に着けるか）を総合的に見て，納期を判断する。

　この荷繰調整に時間がかかっていた根本的な原因は，商品受注の窓口となる需給部が荷繰調整システムの情報を全く見られないことだった。そのため，需給部は在庫のない工場に荷繰調整を依頼してしまうケースが少なくなかった。そうなると，最初に打診した工場から断られた需給部は，別の工場に発注できるかどうかを確認する作業が繰り返し発生する。もし，需給部があらかじめ各工場の情報を把握していれば，無駄なやり取りで発生する時間を減らせるはずだ。

　この問題を解決するために，新システムでは荷繰調整に必要な情報を需給部と共有することにした。

　こうした合理化の積み重ねにより，出光興産は延べ2万3000時間に及ぶ業務をシステム化することに成功した。